Skip to content

SSF 97 pantry management backend#76

Open
swarkewalia wants to merge 48 commits intomainfrom
sk/SSF-97-pantry-management-backend
Open

SSF 97 pantry management backend#76
swarkewalia wants to merge 48 commits intomainfrom
sk/SSF-97-pantry-management-backend

Conversation

@swarkewalia
Copy link

@swarkewalia swarkewalia commented Dec 3, 2025

ℹ️ Issue 97

Closes 97

📝 Description

Added a new endpoint (getApprovedPantries) to return all information necessary for the pantry management frontend about pantries with 'approved' status - includes assigned volunteers.
Added a second new endpoint (updatePantryVolunteers) to overwrite the set of volunteers assigned to a pantry with a new set of volunteers.
Added a type file for pantries and included ApprovedPantryResponse and AssignedVolunteer types.
Added a controller test for each endpoint.

✔️ Verification

Tested both endpoints using curl. Made sure GET endpoint retrieved all approved pantries with assigned volunteers, and that the PUT endpoint overwrites volunteer assignments successfully.

@swarkewalia swarkewalia changed the title get approved and update volunteer endpoints SSF 97 pantry management backend Dec 4, 2025
@dburkhart07
Copy link

See slack comment

@dburkhart07 dburkhart07 self-requested a review December 6, 2025 18:27
@swarkewalia swarkewalia force-pushed the sk/SSF-97-pantry-management-backend branch 2 times, most recently from 313c63d to 2577fbe Compare January 18, 2026 04:21
@swarkewalia swarkewalia force-pushed the sk/SSF-97-pantry-management-backend branch from 2577fbe to 265bad6 Compare January 18, 2026 04:39
Copy link

@dburkhart07 dburkhart07 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make these initial changes, also see message I sent you.

yarn-error.log
testem.log
/typings
.nx

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this here? Can we get rid of it?

pantries?: Pantry[];
}

export interface UserDto {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not be deleted either I dont think.

@sam-schu sam-schu removed the blocked label Jan 18, 2026
Copy link

@dburkhart07 dburkhart07 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few initial things. Also, I do not see the second half of the ticket requirement to make a new endpoint for this: Add a new endpoint to overwrite the set of volunteers assigned to a pantry with a new set of volunteers for intended use case

email: string;
phone: string;
};
refrigeratedDonation: string;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should use the enum

};
refrigeratedDonation: string;
allergenClients: string;
status: string;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here

@@ -1,3 +1,35 @@
export interface ApprovedPantryResponse {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we are going to need more info than this for our approved pantry response. For one, all these pantries are approved so we shouldnt need the status. Additionally, check out the Figma for the frontend: https://www.figma.com/design/brc5luMhizIFp893XIutYe/SP26---SSF-Designs?node-id=756-11085&t=3UiKr0MdYxCcdUUK-0

The modal that pops up with Pantry Details should tell you what information we need.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, there may have been some confusion here. It's fine if we have to make another API call to get the full details about a pantry when the user navigates to the "pantry details" page - we just need the info for the main table (as well as the IDs necessary to be able to navigate to the other pages)

}


async getApprovedPantriesWithVolunteers(): Promise<ApprovedPantryResponse[]> {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comment in the type.ts file, this will need to change too.

return this.pantriesService.getPendingPantries();
}

@Get('/approved')

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should write a test for this as well.

@dburkhart07
Copy link

dburkhart07 commented Feb 13, 2026

Final comments:

  • We need to add volunteers to the relations that are returned in the getApprovedPantries function
  • We need to also make it so that, we know every volunteerId being included is an actual volunteer. To do this, we will need to find the user, and confirm the user.role == Role.VOLUNTEER
  • Make sure that in the orders.service.spec.ts file, we delete the mock variables, as they're not being moved
  • Make sure the ci tests are passing

Copy link

@dburkhart07 dburkhart07 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Thanks for responding to so much back-and-forth 🔴🐼

@Yurika-Kan Yurika-Kan self-requested a review February 19, 2026 06:55
Copy link
Collaborator

@Yurika-Kan Yurika-Kan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

first round of review!
found a field that was missing

done: jest tests ran
pending: testing via postman

litttt

contactPhone: pantry.pantryUser.phone,
shipmentAddressLine1: pantry.shipmentAddressLine1,
shipmentAddressCity: pantry.shipmentAddressCity,
shipmentAddressZip: pantry.shipmentAddressZip,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shipmentAddressState is also missing here!

contactEmail: string;
contactPhone: string;
shipmentAddressLine1: string;
shipmentAddressCity: string;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • state

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can zip be after state & country?

Copy link
Collaborator

@Yurika-Kan Yurika-Kan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hefty second review! some small changes, adding auth gating, testing, and a bit more! thanks for the great work so far <3

(update) tested:

  • postman calls

shipmentAddressLine1: '123 Main Street',
shipmentAddressCity: 'Boston',
shipmentAddressZip: '02101',
shipmentAddressState: 'MA',
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you make it so state comes before zip?

@@ -16,6 +17,7 @@ import { Roles } from '../auth/roles.decorator';
import { ValidationPipe } from '@nestjs/common';
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we add this to the list of imports above in the first lines?

import { ValidationPipe } from '@nestjs/common';
import { PantryApplicationDto } from './dtos/pantry-application.dto';
import { ApiBody } from '@nestjs/swagger';
import { ApprovedPantryResponse } from './types';
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also here add this import into the list of imports below so that we aren't unnecessarily calling multiple imports of the same file

@@ -56,6 +58,11 @@ export class PantriesController {
return this.pantriesService.getPendingPantries();
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since we began auth gating endpoints by role, let's continue that here by making this only accessible to admin role - aligned with the feature implications of this backend ticket

attachments,
);
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here with annotating this to be accessible only for admin

name: string;
email: string;
phone: string;
role: string;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we have a user enum that we should use instead of string here to determine role!

},
],
}).compile();

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing tests for getApprovedPantriesWithVolunteers & updatePantryVolunteers

import { PantryApplicationDto } from './dtos/pantry-application.dto';
import { OrdersService } from '../orders/order.service';
import { Order } from '../orders/order.entity';
import { ApprovedPantryResponse } from './types';
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lets add this to the list of imports below!

contactEmail: string;
contactPhone: string;
shipmentAddressLine1: string;
shipmentAddressCity: string;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can zip be after state & country?

name: string;
email: string;
phone: string;
role: string;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't think we need to save role of the volunteer here - they should always be volunteer - could you delete this everywhere in this implementation? @sam-schu lmk thoughts

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine either way - this type seems to only be used as part of the return of the endpoint to get info about the approved pantries, where I agree it's not strictly necessary that we return the role of every assigned volunteer but it also doesn't hurt anything

Copy link
Collaborator

@sam-schu sam-schu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, for the endpoint to get info about approved pantries I would recommend either:

  • return full pantry/volunteer details as you pretty much are now, but simplify by returning them as returned by typeorm, rather than mapping all the individual fields
    • can define return types in terms of Pantry and User rather than making new interfaces
    • just make sure to remove the users' cognito subs from the data being returned
  • or limit returned info to what is necessary for the frontend, which will make the map and interfaces much more concise

relations: ['volunteers', 'pantryUser'],
});

return pantries.map((pantry) => ({
Copy link
Collaborator

@sam-schu sam-schu Feb 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you take a look at what the return from the above call to TypeORM looks like? That should likely have all the information we need, it doesn't look like this map is doing much other than copying all the fields from one object to another. If we do go with the current approach rather than just returning pantries (with volunteers' cognito subs removed), we should make things more concise by limiting to the fields that are actually needed by the admin pantry management page this endpoint is for

newsletterSubscription: pantry.newsletterSubscription ?? false,
volunteers: (pantry.volunteers || []).map((volunteer) => ({
userId: volunteer.id,
name: `${volunteer.firstName} ${volunteer.lastName}`,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should not be combining the first and last names into one field here, this will make things more difficult for the frontend which needs to show the user's initials

@@ -1,3 +1,40 @@
export interface ApprovedPantryResponse {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both of these interfaces look very similar to the Pantry and User entity types. Can we define the return types using those rather than re-listing out all their fields?

@@ -1,3 +1,35 @@
export interface ApprovedPantryResponse {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, there may have been some confusion here. It's fine if we have to make another API call to get the full details about a pantry when the user navigates to the "pantry details" page - we just need the info for the main table (as well as the IDs necessary to be able to navigate to the other pages)

name: string;
email: string;
phone: string;
role: string;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine either way - this type seems to only be used as part of the return of the endpoint to get info about the approved pantries, where I agree it's not strictly necessary that we return the role of every assigned volunteer but it also doesn't hurt anything

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants